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1 TRANSACTION VERIFICATION SYSTEM 

2 

3 Background to the invention 

4 

5 . This invention relates to a system for processing financial transactions. 

6 

7 In the current systems employed for the authorisation of financial transactions, it is difficult 

6 and often impossible to obtain a firm guarantee that the person initiating the transaction is 

9 authentic and authorised to conclude the transaction. Currently the processes employed 

10 by financial institutions do little more than guarantee the availability of funds in the account 

11 in issue. It is a process that provides no more than authorisation of the transaction after 

12 ensuring that funds are available to complete the transaction. Unfortunately, however, the 
fs process does not provide any form of authentication or any other indication that the 

14 individual making the transaction is indeed the authentic and authorised to operate the 

15 particular account 

16 

17 This lack of authentication is a problem and gives rise to a number of fraud situations, 

18 particularly in internet-based transactions. 

19 

20 The invention also finds application in avoiding fraud in cheque-based transactions. 

21 Notwithstanding the increase in electronic funds transfer mechanisms and the increased 

22 use of such mechanisms, cheques remain one of the dominant methods of payment in 

23 commerce, particularly where larger amounts are concerned. Unfortunately, cheques are a 

24 relatively easy target for fraud. This is due largely to the fact that cheque fraud detection 

25 remains a predominately manual operation. 

2(5 

27 This invention seeks to address the above mentioned problems by providing an 

28 authentication mechanism and process that takes place before the transaction is 

29 authorised. 

30 

31 In addition, the invention seeks to introduce a mechanism at least partly to automate these 

32 processes rather than relying on current manual verification and authentication processes. 
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2 



1 In essence, this invention is characterised by the use of two separate (parallel) 

2 communication channels to authorise a transaction. Practically, this implies that a primary 

3 data channel (Public subscriber Telephone Network (PSTN), radio or the like) is used to 

4 communicate between the merchant terminal and the bank, and a different data channel (a 

5 mobile phone network for instance) is used for the authentication process between bank 

6 and client. The advantage of this methodology is that if any fraud is perpetrated, the data 

7 on both communication channels would need to be intercepted and synchronised. With a 

8 128-bit encryption key and less than two minutes (in current practice in South Africa) 

9 before the request from the bank server times out, hacking into this system is improbable. 

10 

11 This document outlines the use of such a parallel authorisation and authentication system 

12 using the PSTN as the primary data channel and a mobile phone (GSM) network as the 

13 channel running in parallel for authentication. 

14 

15 In the context of this specification: 

16 

17 a "server" is any entity, machine, system or application that provides the 

18 functionality required by the financial transaction verification system of this 

19 invention; 

20 

21 an "authorisation code" is a code or other data, normally kept secret, that is 

22 required to allow a transaction to be concluded; 

23 

24 "control" is the ability to authorise or prohibit the processing of a transaction, 

25 normally by providing or withholding an authorisation code or other data required to 

26 allow the transaction to be concluded; 

27 

28 the terms "telecommunication" and "telecommunications" are used largely in the 

29 conventional sense of referring to communications on a telephone network, but the 

30 terms are not necessarily intended to be limited to such an interpretation in every 

31 instance and where a wider interpretation is possible in the context, then the terms 

32 should be interpreted widely, such as to include two-way radio communications for 

33 instance; 
34 

35 whilst the specification outlines the use of a parallel authorisation and 

36 authentication system using the PSTN as the primary data channel and a mobile 

37 phone (GSM) network as the channel running in parallel for authentication, it will be 
3d appreciated that this is done purely for the purposes of illustration and is not 
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I intended to limit the scope of the invention to such communication channels. 

2 
3 

4 Summary of the invention 

5 
6 

7 The financial transaction verification system of this invention comprises: 

8 

9 a transaction processing client; 

10 

II a transaction processing server under the control of a financial services provider 

12 

1^ a programmable telecommunications client under the control of a transaction 

u initiator; 

15 

16 the transaction processing client, the transaction processing server and the 

'7 telecommunications client all being connected to or adapted for connection to a 

18 telecommunications network; 

19 

20 the transaction processing client being adapted, when in use a transaction is 

21 initiated and processed through the transaction processing client, to record: 

22 

23 data pertaining to a transaction initiated, in use, by the transaction initiator; 

24 and 

25 

26 data pertaining to a financial account of the transaction initiator with the 

27 financial services provider; 

28 

29 the transaction processing client being adapted to transmit the recorded data to the 

30 transaction processing server by way of the telecommunications network; 

31 

32 the transaction processing server being adapted to make use of data pertaining to 

33 the transaction initiator and the telecommunications client previously stored with the 

34 financial services provider to formulate a transaction authorisation request to the 

35 telecommunications client; 

36 

37 the transaction processing server being adapted to transmit the transaction 

38 authorisation request to the telecommunications client by way of the 



i 



WO 2005/001670 



PCT/ZA2004/000072 



4 

1 telecommunications network; 

2 

3 the telecommunications client being programmed to require the entry of an 

4 authorisation code into the telecommunications client as a precondition for the 

5 further processing of the transaction authorisation request; and 
6 

7 the telecommunications client being programmed, further, to transmit a process 

8 outcome message to either or both the transaction processing server and the 

9 transaction processing client, which process outcome message: 

10 

1 1 if the incorrect authorisation code is entered, is constituted by a transaction 

12 cancellation signal; and 

13 

14 if the correct authorisation code is entered, is constituted by a transaction 

*5 authorisation signal. 

16 

17 The financial transaction verification system may conveniently use a mobile communication 

is device (such as a mobile phone) that is personal to the transaction initiator as the 

19 telecommunications client, in which case: 

20 

21 the transaction initiator data previously stored with the financial services provider 

22 includes unique mobile communication device data, which is data that is unique to 

23 and stored in the mobile communication device; 

24 

25 the transaction processing server is adapted to transmit the previously stored 

26 unique mobile communication device data to the mobile communication device 

27 together with the authorisation request; 

23 

29 the mobile communication device is programmed, on receipt of the transmitted 

30 da ta, to compare the transmitted data to the equivalent unique mobile 

31 communication device data stored in the mobile communication device; 

32 

33 the telecommunications client is programmed, further, to transmit a process 

24 outcome message to either or both the transaction processing server and the 

35 transaction processing client, which process outcome message may, alternatively, 

36 be constituted by a transaction cancellation signal or a transaction authorisation 

37 signal; 

08 
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1 the mobile communication device being programmed, further: 

2 

3 if the comparison between the transmitted data and the equivalent data 

4 stored in the mobile communication device fails, to transmit a process 

5 outcome message constituted by a transaction cancellation signal; and 

6 

7 if the comparison is successful, to require the entry, into the mobile 

s communication device, of the authorisation code previously provided as a 

9 precondition for the further processing of the transaction authorisation 

10 request; and 

11 

12 if the incorrect authorisation code is entered, to transmit a process outcome 

13 message constituted by a transaction cancellation signal; and 

14 

15 if the correct authorisation code is entered to transmit a process outcome 

message constituted by a transaction authorisation signal. 

17 

id The system may be adapted to cancel the transaction in the event of the receipt, by the 

19 telecommunications client, of a transaction cancellation signal and to allow the transaction 

20 to proceed to finality in the event of the receipt, by the telecommunications client, of a 

21 transaction authorisation signal. 

22 

23 The invention includes one or more of: 

24 

25 a transaction processing client; 

26 

27 a transaction processing server; 

23 

29 a telecommunications server; and 

30 

31 a telecommunications client 

32 

33 for use with a system such as that described above. 

34 

35 In addition, the invention includes a method of verifying a financial transaction comprising 

36 the steps of: 

37 

6 initiating a transaction at a transaction processing client; 
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recording, by means of the transaction processing client, data pertaining to the 
transaction together with data pertaining to a financial account of the transaction 
initiator with a financial services provider; 

transmitting the data so recorded from the transaction processing client to a 
transaction processing server under control of the financial services provider, by 
way of a telecommunications network, 

supplying, to the transaction processing server, data previously stored with the 
financial services provider and pertaining to a telecommunications client which is 
under the control of the transaction initiator; 

transmitting an authorisation request pertaining to the initiated transaction to the 
telecommunications client; 

requiring, on receipt of such a transaction authorisation request, the entry into the 
telecommunications client, of an authorisation code as a precondition for the further 
processing of the transaction authorisation request; 

transmitting a process outcome message to either or both the transaction 
processing server and the transaction processing client, which process outcome 
message: 

if the incorrect authorisation code is entered, is constituted by a transaction 
cancellation signal; and 

if the correct authorisation code is entered, is constituted by a transaction 
authorisation signal. 

In the event that the telecommunications client is a mobile communication device personal 
to the transaction initiator (such as a mobile phone), the method described above may 
include the preliminary step of storing data unique to and stored in the mobile 
communication device at the financial services provider as part of the communications data 
pertaining to the transaction initiator, the method including the additional steps of: 

transmitting the unique mobile communication device data from the transaction 
processing server to the mobile communication device together with the 
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1 authorisation request; 

2 

3 in the mobile communication device, comparing, on receipt of the transmitted data 

4 and authorisation request, the transmitted unique mobile communication device 

5 data to the equivalent mobile communication device data stored in the mobile 

6 communication device; and 

7 

8 if the comparison between the transmitted data and the equivalent data 

9 stored in the mobile communication device fails, transmitting a transaction 

10 cancellation signal to either or both the transaction processing server and 

11 the transaction processing client; and 



12 

13 



if the comparison is successful, requiring the entry of the authorisation code 

14 previously provided into the mobile communication device as a precondition 

15 for the further processing of the transaction authorisation request; and 

16 

17 if the incorrect authorisation code is entered, transmitting a transaction 

18 cancellation signal to either or both the transaction processing server and 

19 the transaction processing client; and 



20 



21 if the correct code is entered, transmitting a transaction authorisation signal 

22 to either or both the transaction processing server and the transaction 

23 processing client. 

24 

25 A method of verifying a financial transaction may conveniently include the additional steps 

26 of: 

27 canceling the transaction in the event of the receipt, by the telecommunications 
23 client, of a transaction cancellation signal; and 

29 

30 allowing the transaction to proceed to finality in the event of the receipt, by the 

31 telecommunications client, of a transaction authorisation signal. 

32 

33 The method of verifying a financial transaction finds additional application in verifying 

34 transactions involving the use of a documentary negotiable instrument, in which event the 

35 method may conveniently comprise the steps of: 

36 

37 initiating the transaction by a participating negotiable instrument issuer issuing the 

2$ negotiable instrument manually; 
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1 



2 recording, by means of the transaction processing client, data pertaining to the 

3 transaction including predetermined data pertaining to the negotiable instrument; 



4 



10 
11 



5 transmitting the data so recorded from the transaction processing client to the 

6 transaction processing server by way of the telecommunications network, 

7 

8 transmitting, to either or both the financial services provider and the transaction 

9 processing server, a negotiable instrument issuer code unique to the negotiable 
instrument issuer, thereby to confirm, to the transaction processing server, the 
transmitted data pertaining to the transaction including the predetermined data 

12 pertaining to the negotiable instrument; 

13 

14 recording, at the transaction processing server, the data so confirmed; and 

15 

16 comparing, when in use the negotiable instrument is presented for payment, the 

17 data on tne f ace of the documentary negotiable instrument with the data recorded 

18 in tne transaction processing server in respect of that negotiable instrument. 

19 

20 In this way the negotiable instrument issuer by using a unique negotiable instrument issuer 

21 code, in essence places an "electronic signature" on the negotiable instrument. If the data 

22 on the face of the negotiable instrument is modified, the negotiable instrument will fail the 

23 comparison step outlined above when the negotiable instrument is presented for payment, 

24 in which event payment can be refused. 

25 

26 The invention extends to the verification of financial transactions involving the use of a 

27 communications enabled transaction terminal as the transaction processing client, the 

28 method including the steps of: 

29 

30 with the us © of the mobile communication device, formulating and encrypting, by 

31 means of a first encryption key and data unique to the mobile communication 

32 device, a transaction request to be transmitted to the transaction terminal and 



33 
34 
35 



transmitting a transaction request directly to the transaction terminal with the use of 
the mobile communication device, using a method of communication for which the 
38 transaction terminal is enabled; 

37 

38 transmitting the transaction request from the transaction terminal to the transaction 
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1 processing server; 

2 

3 at the transaction processing server: 

4 

5 receiving the transaction request; 

6 

7 identifying the mobile communication device using the data unique to the 

8 mobile communication device; 
9 

10 retrieving the first encryption key, previously stored at the transaction 

11 processing server in respect of the mobile communication device; 

12 

' 3 decrypting the encrypted transaction request using the first encryption key; 

14 

f5 processing the transaction request and generating a process outcome 

16 message pertaining to the result of processing of the transaction request; 

17 

18 generating a second encryption key, storing the second encryption key in 

*9 the transaction processing server; 

20 

21 transmitting the second encryption key to the transaction terminal; 

22 

23 encrypting the process outcome message using the second encryption key; 

24 and 

25 

26 transmitting the encrypted process outcome message to the mobile 

27 communication device; 

28 

29 at the mobile communication device, extracting and storing the second encryption 

20 ke Y Q nd transmitting the encrypted process outcome message to the transaction 

31 terminal; and 

32 

33 at the transaction terminal, decrypting the encrypted process outcome message 

34 and applying the decrypted process outcome message to actuate the transaction 

35 terminal. 

36 
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1 Brief description of the drawings 

2 

3 The invention will be further described with reference to the accompanying drawings in 

4 which: 

5 

6 Figure 1 is a block diagram illustrating a current credit card transaction cycle; 

7 

8 Figure 2 is a block diagram illustrating an internet transaction cycle; 

9 

10 Figure 3 is a block diagram illustrating a credit card transaction cycle using the 

* * system of this invention; 

12 

13 Figure 4 is a block diagram illustrating an internet-based credit card transaction 

™ cycle using the system of this invention; 

15 

16 Figure 5 is a block diagram illustrating an internet-based banking transaction cycle 

* 7 using the system of this invention; 

18 

19 Figure 6 is a block diagram illustrating a cheque transaction cycle using the system 

20 of this invention; 

21 

22 Figure 7 is a block diagram illustrating transaction authorisation and authentication 

23 in a cheque transaction cycle using the system of this invention; 

24 

25 Figure 8 is a flow chart illustrating one implementation of the invention; 

26 

27 Figure 9 is a block diagram illustrating a cheque fraud protection system according 

25 to the invention; 

29 

30 Figure 1 0 is a block diagram illustrating apparatus for implementing the method of 

31 the invention in respect of transactions involving the use of a communications 

32 enabled transaction terminal as the transaction processing client; and 

33 

34 Figure 11 is a block diagram illustrating (partly in flow-chart form), one 

35 implementation of the aspect of the invention illustrated in Figure 10. 

36 
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Description of embodiments of the invention 

The financial transaction verification system of the invention, is possibly best understood 
with reference to the example illustrated in the flow chart of Figure 8. 

The flow chart illustrates the example of a relatively simple financial transaction involving a 
point of sale (POS) payment terminal at which credit cards or cheques are used to pay for 
the purchase of goods. Using the example of a credit card, the credit card belongs to the 
person who makes a purchase and who will be referred to as the transaction initiator in this 
specification. The transaction initiator will have a credit card account linked to the credit 
card with a bank or other financial institution, which is referred to in this specification as a 
financial services provider. 

The financial services provider operates and serves a network of point of sale terminals 
and other electronic transaction terminals, such as automated teller machines (ATM's) and 
the computers of its banking clients in circumstance where those computers serve as 
internet banking terminals. 

This network of terminals is normally operated from a central server or servers which, in 
this specification, are referred to as the transaction processing server. 

In a typical credit card transaction, the transaction details are entered at the POS terminal 
(the transaction processing client) where the credit card is swiped to obtain details 
pertaining to the transaction initiator, typically the credit card account number held with the 
financial services provider. 

The transaction processing client then dials up the transaction processing server 
automatically, normally making use of a fixed line telecommunication network or PSTN. 

In the normal course of events, using current authorisation systems, the transaction is 
authorised or declined in a process of communication between the transaction processing 
server and the financial services provider. The result of this authorisation process is then 
communicated back to the transaction processing client by way of the fixed line network. 

It will be appreciated that the network need not be a fixed line network, particularly since 
mobile communication networks are being used with increasing frequency in situations 
such as this. 
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1 



A number of credit card fraud schemes in current use are unlikely to be detected in a 

2 simple authorisation process such as this, particularly where a credit card is duplicated or 

3 cloned. 



4 



5 For this reason the system of the invention proposes the use, essentially, of a two-part 

6 authorisation process - one that includes a first, transaction initiation component and a 

7 final transaction authorisation component, the latter directed at final transaction 

8 authorisation and account holder (transaction initiator) authentication. This authentication 

9 step is carried out by the transaction initiator, who is best placed to control and direct such 

10 an authentication step, with assistance from the system and the financial services provider, 

11 which provides credibility to the transaction initiator and which also serves as the 

12 transaction record keeper, the latter function is important, since it serves to authenticate 

13 not only the transaction and the transaction initiator but also the fact that the transaction 
initiator did in fact authorise the transaction, thereby serving to reduce the possibility of 



14 



15 chargeback fraud, which will be described in more detail below. 

16 
17 



18 
19 
20 



Using the simple credit card transaction described above, the example of the invention 
illustrated in Figure 8 directs the transaction initiation component on a conventional 
communications stream, using the POS terminal (the transaction processing client) and the 
transaction processing server and financial services provider in their normal functions. At 

21 this point, however, the process loops into a final transaction authorisation component that 

22 requires final authorisation by the transaction initiator - the card holder who has authority 

23 over the account - using a separate communications stream constituted by a mobile 

24 communications network. 

25 

26 In the example illustrated, the communications network is a GSM network on which data 

27 transfer is undertaken by way of SMS communications. It will be appreciated that GPRS 

28 (General Packet Radio Service) communication protocols would work equally well if not 

29 better. 

30 

31 Referring to the flow chart, the card holder as transaction initiator initiates a transaction at 

32 the POS terminal that serves as a transaction processing client. Transaction data is 

33 entered into the transaction processing client, which data is normally constituted by the 

34 transaction value and details of the transaction initiators credit card account, which details 

35 are obtained in conventional fashion by swiping the credit card through a magnetic stripe 

36 reader forming part of the transaction processing client. 

37 

38 The transaction processing client then, as in the conventional process, dials out to the 
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1 transaction processing server forming part of the financial services provider network and 

2 transmits the transaction data together with the transaction initiator account data to the 

3 transaction processing server as a transaction authorisation request. 

The financial records of the financial services provider are available to the transaction 
processing server and on receipt by the transaction processing server, these records are 
interrogated by the transaction processing server to determine whether or not the 
transaction is financially permissible - essentially to determine whether or not the 
transaction initiator's credit card account has sufficient credit to permit the transaction. If 
not, the transaction processing server simply transmits a signal to the transaction 
processing client to the effect that the transaction is not authorised, as occurs normally in 
12 present day transaction processing systems. 



4 
5 
6 
7 
8 
9 
10 
11 



13 
14 



If the transaction is financially permissible, the transaction processing server looks up the 
15 appropriate communications data of the card holder or transaction initiator in the databases 

of the financial services provider, in this case the mobile phone number of the transaction 
initiator. The transaction processing server then transmits a transaction authorisation 
request to a telecommunications server which, in this, example, will be constituted by an 
19 SMS gateway. On receipt, the telecommunications server converts the transaction 

authorisation re( l uest to a" SMS, which it sends to the telecommunications client 



16 
17 
18 



20 

21 constituted by the card holder's mobile phone 

22 
23 



24 



It will be appreciated that the SMS gateway must, of necessity, be one that enjoys priority 
routing on the mobile communications network so as not to introduce inordinate delays in 
25 the transaction authorisation process. 

26 

27 The card holder now receives an SMS on his or her mobile phone requesting authorisation 

of the transaction. If the card holder is not the transaction initiator, then the card holder can 
cancel the transaction immediately, and, if necessary, alert the financial services provider 



28 
29 



30 and possibly the police that fraud is being perpetrated. 

31 

32 



Upon accepting the option of not authorising (or canceling) the transaction, normally by 
pressing the appropriate key on the mobile phone, the card holder sends an SMS to the 
telecommunications server which converts the SMS and sends a cancellation signal to the 
transaction processing client via the transaction processing server. The POS terminal as 
transaction processing client, will then display a message to the effect that the transaction 



33 
34 
35 
36 

37 cannot be authorised 

38 
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1 In the normal course of events the card holder will be the transaction initiator. 



2 



3 The mobile phone, as telecommunications client, is programmed to display the SMS 

4 containing the transaction authorisation request and to await the entry of an authorisation 

5 code. This code will normally take the form of a personal identification number (PIN) 

6 previously supplied to the card holder by the financial services provider or selected by the 

7 card holder, as the case may be. 



9 Should the card holder elect to accept the option of authorising the transaction, then by 

10 pressing the appropriate key or keys, the mobile phone sends an SMS to the 

11 telecommunications server. 



12 



13 The SMS from the mobile phone (serving as telecommunications client) may contain PIN 

14 and transaction data that is sent via the telecommunications server, to the transaction 

15 processing server. 



13 

17 On receipt by the transaction processing server, the transaction and PIN data is verified. In 

18 particular , the PIN data is verified against card holder account data held by the financial 

19 services provider. If, for some reason, the PIN data is found to be invalid, a cancellation 

20 signal is sent to the transaction processing client which displays a message to the effect 

21 that the transaction cannot be authorised. 

22 

23 In the normal course and since the PIN data has already gone through a verification step in 

24 the telecommunications client, the PIN data will be valid, in which case the transaction data 

25 will be transmitted to the financial services providerfor processing, normally by debiting the 

26 account of the card holder. 

27 

28 The transaction processing server also transmits a transaction authorisation signal to the 

29 point of sale terminal as transaction processing client, which displays a message to the 

30 effect that the transaction has been authorised and produces the normal credit card slips 

31 for signature by the card holder and transaction initiator. 

32 

33 Whilst the system has been described above with reference to a credit card transaction, 

34 the system will work equally well in the verification of the authorisation of other financial 

35 transactions. 

36 

37 For instance, if the transaction processing client is a computer serving as an internet 

38 terminal, the procedure will be almost identical, once again requiring the card holder or 
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1 account holder, as transaction initiator, to enter a PIN number on his or her mobile phone 

2 to verify the authorisation of the transaction. 



3 
4 
5 

6 
7 
8 



11 
12 
13 
14 



17 
18 



23 
24 
25 
26 
27 
23 
29 
30 
31 
32 
33 
34 
35 
36 
37 



Once again, the transaction initiation component and transaction authorisation component 
of the process are carried out on separate communication streams, with the final 
authorisation being provided by the mobile phone of the transaction initiator. 



With the appropriate point of sale terminal, either in the form of a keypad, a cheque reader 
9 or both, the system of the invention can also be adapted to the verification of cheque- 

10 based transactions. 



The transaction verification process follows the course outlined above, with the personal 
authorisation of the transaction initiator being required byway of a PIN code entered on a 
relatively personal device - the mobile phone of the transaction initiator - to provide final 
15 verification of the transaction. 

16 

Various forms of data encryption may be used to encrypt the messages and signals 
transmitted as part of this transaction authorisation and verification process, particularly 
19 bank account and PIN code data. 

2.0 

21 The financial transaction process related above is but one example of the transaction 

22 processing capacity of the system. 



The current system 10 employed for the authorisation of credit card transactions is 
illustrated in Figure 1. In this system a merchant presents a client's credit card 12 to a 
Point-Of-Sale (POS) device 14. The POS device 14 sends a request to the transaction 
processing server of the bank 1 6 that owns the POS device and that therefore "acquires" 
the transaction. This is normally done by means of a Public Subscriber Telephone 
Network (PSTN) line or a radio pad-based service, the South African example of which is 
known as SWIFTNET. The acquiring bank contacts the bank that issued the card (the 
issuer bank 18), through an authorisation network 20 that normally relies on the PSTN. 

Depending on the availability of funds, the request is either approved or denied. 

If approved, funds in the client's account are reserved or transferred to the merchant's 
account by the issuer bank 18, which notifies the acquiring bank 16 accordingly. The 
acquiring bank then notifies the merchant by means of the POS device 14 that the 



56 transaction has been approved. 
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1 

2 At no point in this process is there any guarantee that the person using the credit card is 

3 indeed the rightful owner. This process only guarantees the availability of funds. It is a 

4 process that provides no more than authorisation of the transaction after ensuring that 

5 funds are available to complete the transaction. Unfortunately, however, the process does 

6 not provide any form of authentication or any other indication that the individual making the 

7 transaction is indeed the rightful owner of the card. 
8 

9 The lack of authentication is a problem and gives rise to a number of fraud situations, 

10 particularly in internet-based credit card transactions. 

11 

12 In so-called charge-back fraud, the cardholder typically denies knowledge of the 

13 transaction having taken place, typical examples including the cardholder claiming not to 

14 have received the goods or that the goods do not match what was advertised. A type of 

15 fraud known as "friendly fraud" falls into this category. This occurs when a cardholder 

16 wants to avoid paying for a potentially embarrassing type of purchase (adult content 

17 literature for instance). These types of fraud occur because merchants seldom have the 

18 time (or the ability, in the case of an internet merchant) to authenticate the identity of a 

19 cardholder. As a result, internet merchants in particular remain vulnerable to cardholder 

20 fraud and charge-back fines. 

27 

22 In on-line transactions, it is only the financial institution that issued a particular credit card 

23 that can vouch for the identity and authority of a user of that credit card. 

24 

25 The parallel authentication process of the invention protects the merchant from chargeback 

26 fraud because authentication takes place before the transaction is authorised. This 

27 ensures that the cardholder is aware of the transaction taking place and has the 

28 opportunity to cancel the transaction if it was done fraudulently. The cardholder's 

29 participation in this process is recorded, notably by one or both banks 16, 18. 
30 

31 Credit card transactions are typically categorised into two categories - card present and 

32 card not present transactions (internet, telephone transactions). Skimming fraud occurs 

33 when the data stored on an authentic credit card is copied and transferred onto a fake 

34 card. In an attempt to minimise the risk of this type of fraud, transaction processing 

35 personnel are required to enter certain card information, normally a number printed or 

36 embossed on the card 12. The parallel authentication process of the invention protects the 
.37 cardholder since the card alone cannot complete a transaction. The fraudulent third party 
33 would have to acquire the credit card, cell phone with SIM and the cardholder's 
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authentication PIN before any transaction will be allowed. 



3 Merchant fraud occurs when merchants authorise and capture fraudulent transactions 

4 against the credit card numbers without the cardholder's authorisation. The parallel 

5 authentication process of the invention can alleviate this instance of merchant fraud since 

6 the credit card number alone cannot get a transaction authorised. Any attempt by the 

7 merchant to authorise transactions that are not permitted by the cardholder will be shown 

8 on the cardholder's cell phone where they can be cancelled. The cell phone as 

9 telecommunications client can be programmed for the transaction authorisation request 

10 SMS to include a merchant number, the merchant name or both for subsequent use as 

1 1 evidence of attempted fraud . 



12 



13 Most internet shopping systems (as illustrated in Figure 2) involve entering details of the 

14 transaction initiator's credit card 1 2 on an on-line merchant's web page 22 - normally the 

15 card number, the card expiry date and a CVS number or part thereof (a number normally 

16 printed on the reverse of the card). Using this information, the transaction is normally 

17 authorised. 

18 

19 Again , there is no authentication. Anyone can use the credit card number for purchases on 

20 the net. 

21 

22 The banks have employed methods to combat the potential for fraud in transactions of this 

23 type, normally involving the transmission of one-time-generated passwords to clients. This 

24 method relies on the password reaching the intended client, thus exposing the password to 

25 man-in-the-middle attacks (which normally involve a person masquerading as the proper 

26 destination, intercepting the communication and then misusing the password so 

27 transmitted). To combat these attacks, a number of banks now employ a pop-up keypad 
23 on their websites, the intention being to prevent the keystrokes from being captured via a 
29 computer worm. This system can be circumvented. 

30 

31 The parallel authentication process of the invention transaction cycle includes the existing 

32 bank process, but has an additional process for authentication before the transaction is 

33 approved. 

34 
35 
36 
37 



Online banking (internet banking) is convenient, but without the proper security, this form of 
banking can be hazardous and a number of security systems have been introduced by 
banks, including an on-screen keypad that is displayed on the client* s internet terminal with 
a scrambled keys that are used to enter the client's PIN. Another method employed is 
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sending a generated PIN via SMS to the client in order to facilitate the online transaction. 

These methods tend to introduce new weaknesses and a sense of false security. Firstly, 
the keypad security can be hacked by obtaining the relative mouse click positions. The 
keypad is scrambled based on a set algorithm that can be deciphered. Hiding a computer 
worm or Trojan horse behind the client's firewall exposes the client to fraud and an SMS 
can be diverted to another phone or the phone could have been stolen. 

The parallel authentication process of the invention method can be successfully employed 
for internet banking. Even though it also uses SMS as the communication bearer, the 
client's identity can be guaranteed. If the SMS is diverted to another phone, authentication 
will fail because the SIM number and IMEI number of the phone will differ. 



Notwithstanding the increase in electronic funds transfer mechanisms and the increased 
use of such mechanisms, cheques remain one of the dominant methods of payment in 
commerce, particularly where larger amounts are concerned. Unfortunately, cheques are a 
relatively easy target for fraud. This is due largely to the fact that cheque fraud detection 
remains a predominately manual operation. 

Cheque fraud is so common these days, that many merchants do not accept cheques as 
payment anymore. The risk involved with accepting a cheque is just too great. Common 
problems are Return to Drawer (RD) cheques where funds are not available for the amount 
stipulated in the cheques, cloned cheques where the beneficiary of the cheque is changed, 
forged signatures on cheques and many more. Currently, the banks attempt to do some 
form of authentication by visual signature screening or calling the client if a cheque above 
a certain value is about to be cashed. Only once the client has given his/her permission is 
the cheque cleared. The weakness in the system is that voice calls can be diverted from 
the client's official contact number, to any other telephone number. There is no way the 
bank can be sure that the person on the other end of the line is really the client. 

The parallel authentication process of the invention system properly implemented can limit 
cheque fraud to the absolute minimum. There is no human intervention since the whole 
process is done automatically. 

The cheque fraud protection system illustrated in Figure 9 comprises three discrete 
subsystems: 
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I an issuer subsystem; 

2 

3 a central processing subsystem; and 

4 

5 a presentation point subsystem. 

6 

7 It is anticipated that a large number of negotiable instrument issuers will participate in a 

e system such as this. The same applies to the presentation point subsystem which will see 

9 a large number of presentation points participating in the system. 

10 

II Each issuer subsystem 110 comprises a data entry terminal 1 12 with a local database 1 14 

12 and an issuer front end 116. The issuer front end 1 16 is intended to provide an issuing 

13 user with data entry forms. It also provides an internet link. 

14 

15 The central subsystem 1 1 00 comprises a central database 1 1 02, an issuer interface 1 1 04 

16 and a presentation point interface 1 106. 

17 

1S The presentation points 1 200 each comprise a data entry terminal with a presentation point 

19 front end 1 104 that provides the user at the presentation point with data entry and data 

20 query forms. 

21 

22 In operation, payments are processed through the system as follows. 

23 

24 Cheque issuers wishing to participate in the system must first register with the system. In 

25 the process of registering such a cheque issuer, a negotiable instrument issuer code 

26 unique to the cheque issuer is registered on the system. These unique negotiable 

27 instrument issuer codes will be stored in the central subsystem 1 1 00, either as part of the 

28 central database 1 1 02 or in a separate database. The negotiable instrument issuer code 

29 may be anything from a password to a biometric code and various levels of access may be 

30 provided to facilitate operation of the system. In this way, operator personnel will be able to 

31 enter data pertaining to one or more cheques 1 1 8 into the local database 1 14 forming part 

32 of the data entry terminal 1 1 2 using data entry forms provided by the issuer front end 116. 

33 However, the person with final cheque signing authority at the issuer will then be required 
3-i to enter the negotiable instrument issuer code by means of which the data pertaining to the 

35 cheque or cheques 1 18 will be confirmed and validated. 

36 

37 Most cheque fraud involves manipulation of payee or amount data on the face of the 

36 cheque. The most important data pertaining to a cheque to be entered on the system, 
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therefore, includes data pertaining to the payee, the amount (preferably in words and in 
numbers) and data pertaining to identification of the cheque, typically the cheque number. 
It would be convenient, in addition, to enter data pertaining to the date of issue of the 
cheque. 

Once all of this data pertaining to the cheque 1 18 has been entered into the data entry 
terminal 112, the cheque issuer then validates the data by entering the appropriate 
negotiable instrument issuer code. In this way, the cheque issuer, in effect, places an 
"electronic signature" on the cheque. This "electronically signed" cheque is then sent to 
the payee for processing in the normal course. At the same time, the issuer front end 1 1 6 
transmits the validated data pertaining to the cheque 1 1 8 by way of an internet link to the 
issuer interface 1104 in the central subsystem 1100 which transmits the data for 
processing and storage in the central database 1102. 

The cheque 118, having made its way to the payee, is then presented for payment at a 
presentation point 1 200 which may be constituted by the bank of the payee, a bank teller or 
some other cheque clearing facility. 

In a conventional cheque processing system the cheque 118 will be validated upon 
presentation using largely manual techniques, including visual inspection of the cheque for 
possible tampering and forgery and visual comparisons of the actual signature of the 
cheque signatory with sample signatures of that signatory, once again to determine if any 
forgery has taken place. 

In contrast with this, the system of the invention requires no such inspection. 

At the presentation point 1200, the relevant data pertaining to the cheque 1 18 is simply 
entered into the presentation point front end 1 104 forming part of the presentation point 
data entry terminal 1102. The presentation point front end 1104 communicates, via 
internal or internet link with the presentation point interface 1 106 of the central subsystem 
1100 which draws the validated data pertaining to the cheque 118 into the presentation 
point front end 1104. This allows immediate comparison between the validated data 
pertaining to the cheque 1 1 8 with the data appearing on the face of the cheque 1 1 8 at the 
time of presentation. 



No other visual inspection or comparisons are required. If the data on the face of the 
cheque 1 1 8 corresponds identically with the validated data stored in the central database 
1 1 02, the cheque can be cleared for payment or the account of the payee can be credited. 
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1 

2 

3 If, on the other hand, the data on the face of the cheque 118 does not correspond 

4 identically with the corresponding data stored in the central database 1 102, the cheque 

5 cannot be cleared for payment. 

e 

7 Other than this, no inspection of the cheque is required nor is any comparison of 

8 signatures required. 

9 

10 The invention extends to the verification of financial transactions involving the use of a 

11 communications enabled transaction terminal as the transaction processing client, as 

12 illustrated in Figures 1 0 and 1 1 . 

13 

14 The invention will be described with reference to the use of a cellular telephone or mobile 

15 telephone as the personal communication device. In addition, the invention will be 

16 described with reference to a point of sale (POS) terminal or an automated teller machine 

17 (ATM) as a transaction terminal. This is done purely by way of example and it is not 

18 intended thereby to limit the invention. 

19 

20 The system 310 illustrated in Figure 10 is a transaction processing system that utilises a 

21 cellular telephone 312 to communicate with a POS terminal or ATM 314. Transactions 

22 requested within the transaction processing system 310 will require authorisation by a 

23 transaction processing authority constituted, in this case, by a financial services provider 

24 316. For ease of reference, the transaction terminal will be taken to be an ATM. 

25 

26 Communications between the ATM 314 and the financial services provider 316 are byway 

27 of a GSM communicator 318. Alternatively or in addition, communication between the 
23 ATM 314 and the financial services provider 316 may take place on conventional 

29 communication networks incorporating the ATM 314, such as a conventional telephone 

30 network. 

31 

32 To enhance the security of the transaction processing system 310, communications 

33 between the cellular telephone312 and the ATM 314 are by way of very short range 

34 communications links. Most cellular telephones are equipped with infrared transceivers 

35 320. Infrared is a relatively secure form of short range communication. The ATM 314 can 

36 be fitted with an infrared transceiver 322 relatively simply. 

37 

33 A person wishing to initiate a transaction simply enters the transaction details on the 
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1 cellular telephone 312 and, using the appropriate features on the telephone, transmits a 

2 first infrared signal 324 to the ATM 314. 

3 

4 This process is best illustrated with reference to Figure 1 1 . 

5 

6 As can be seen from Figure 1 1 , a person wishing to initiate a transaction starts off by 

7 entering transaction data (DTrr) into the telephone 312. Upon registration within the 

8 transaction processing system 310, the person concerned will have been issued with a 

9 personal identification number (PIN) and at this point the person will be prompted to enter 

10 the PIN as data (DPIN) into the cellular telephone 312. Within the cellular telephone 312, 

11 the data so entered (DTrr and DPIN) will be encrypted using a first encryption key (K1) as 

12 well as the identification number (ID) of the telephone 31 2 (which may be a manufacturer's 

13 serial number or some other telephone identification number allocated upon registration 

14 within the system 310) and the data previously entered (DPIN and DTrr ). Not all of this 

15 information needs to be used in preparing the encrypted transaction request - E(DTrr). 

1Q 

17 The encrypted transaction request (E(DTrr)) is then transmitted to the ATM 314 by way of a 

16 first infrared transmission 324. The telephone ID can be sent as clear text. 

19 

20 On receipt within the ATM 314, the encrypted transaction request (E(DTrr) ) together with 

21 the telephone ID is transmitted by way of a transmission 326 to the financial services 

22 provider 316. 

23 

24 The message received at the financial services provider 316 (E (DTrr): ID) must now be 

25 decrypted. 

26 

27 The financial services provider 316 has data pertaining to the user and the telephone 312 

28 stored in its databases, which data is linked to the telephone 31 2 by way of the telephone 

29 ID, the most important being data pertaining to the user's PIN (DPIN) and the first 

30 encryption key (K1). The manner in which encryption keys are generated and stored will be 

31 described in more detail below. 

32 

33 On receipt of the encrypted transaction request (E (DTrr): ID), the financial services 

34 provider 316 retrieves this stored data and, using this data (particularly K1 :DPIN) it is able 

35 to decrypt the encrypted transaction request (E(DTrr))and to process the transaction 

36 request. 

37 

3d The outcome of this process will either be positive (for instance to dispense funds or to 
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1 display account information) or there will be some other outcome (for instance, not to 

2 dispense funds or not to display account information, transfer funds or some other 

3 message). 

4 

5 The process outcome message must be communicated both to the person requesting the 

6 transaction and to the ATM 314, since the ATM 31 4 in particular will be required to perform 

7 certain functions in response thereto. In view of the potential sensitivity of this information, 
a this information is encrypted. 

9 

10 The process of encryption is undertaken by the financial services provider which generates 

11 a second encryption key (K2). The second encryption key (K2) is stored in the databases 

12 of the financial services provider 316 and linked to the telephone ID to facilitate future 

13 retrieval of the key. The second encryption key (K2) or a derivative thereof will be used as 

14 the decryption key (K1) in the next transaction processing cycle. 
15 

16 Assuming that the transaction is authorised, the financial services provider generates a 

17 transaction authorisation message (DTra). The financial services provider 316 encrypts 

18 the transaction authorisation message (DTra) using the second encryption key (K2) and 

19 other data typically the telephone ID, the PIN number (DPIN) and the data pertaining to the 

20 transaction authorisation message (DTra). 

21 

22 The encrypted transaction authorisation message (E(DTra)) is then transmitted to the 

23 telephone 31 2 by way of the GSM network, the most convenient form of transmission being 

24 as a Short Message Service (SMS) message 328. At the same time, the financial services 

25 provider 316 transmits the second encryption key ((K2)) to the ATM 314, by way of a 

26 communication 330 between the financial services provider 316 and the ATM 314. 
27 

23 On receipt within the telephone 312, the encrypted transaction authorisation message 

29 (E(DTra)) is transmitted to the ATM 314 by way of a second infrared message 332. 

30 

31 Within the ATM 314 the encrypted transaction authorisation message (E(DTra)) is 

32 decrypted using the second encryption key (K2) received from the financial services 

33 provider 316. The second encryption key (K2) is transmitted to the telephone 31 2 as part 

34 of the infrared communication 332 and the decrypted transaction authorisation message 

35 (DTra) is used to direct the operation of the ATM 314. In this example, the ATM 314 is 

36 instructed to dispense funds to the person who originally requested the transaction. 

37 

3d Within the telephone 312, the second encryption key (K2) is now stored in a database. 



WO 2005/001670 



PCT/ZA2004/000072 



24 



1 internet banking is illustrated in Figure 4. The client logs onto the bank's internet banking 

2 web page. The authentication server sends an authentication request to the client's cell 

3 phone. The client confirms he/she is aware of the log on request and enters his/her PIN. If 

4 the PIN, SIM number and IMEI number coincides with the records, the client is given 

5 access to his/ her accounts. 
6 

7 A further example of the financial transaction verification system of the invention as applied 

e to cheque transactions is illustrated in Figures 6 and 7. 

• 9 

10 When a client's cheque is presented for payment and before the cheque is cleared, the 

1 1 bank sends the cheque information to the client's cell phone. The client confirms he/she is 

12 aware of the transaction and enters his/her password. An encrypted SMS is then sent from 

13 the client's cell phone to the authentication server via the WIG. The authentication server 

14 authenticates that the correct client responded by cross checking the IMEI, SIM card 

15 number, MSISDN and the password. Any variances in these parameters will result in 

16 authentication failing and the cheque being rejected. 

17 

18 This system can also be used in a process similar to the credit card transaction cycle (see 

19 Figure 7). The vendor can thus be certain that there is enough funds in the clients account 

20 and that the client is the rightful owner of the cheque account. 



